home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
misc
/
merit
/
noop
/
papers
/
tools.rfc
< prev
next >
Wrap
Text File
|
1992-03-14
|
23KB
|
749 lines
DRAFT - Tools RFC
S. Hares and C. Wittbrodt
March 14, 1992
version 1
1
Draft - TOOLS RFC March 14, 1992
1. STATUS
This memo specifies tools which are necessary to debug problems
in the deployment and maintenance of networks using ISO 8473[1],
the connectionless network layer protocol (CLNP). This document
will be submitted to the RFC editor as a proposed standard for
the OSI Internet.
To support some of the needed tools (ping and traceroute) this
memo specifies the long term mechanism outlined in RFC1139
[2]. RFC 1139 specifies that when an ISO standard is adopted that
provides functionality similar to that described by RFC 1139,
then RFC 1139 will be come obsolete and superseded by the ISO
standard. ISO work is progressing on an ISO echo function, but
not completed yet and at this time, there is no estimated date
of completion. When an echo function is defined for an ISO
standard, both the RFC 1139 echo function and the ISO echo
function will need to be supported for a period of transition.
Once the ISO echo function has been adopted (and RFC 1139
obsolete by the ISO standard), an RFC defining the transition
period for support of both echo functions will be written to
supersede this document.
2. ABSTRACT
This memo specifies the following three necessary tools to debug
problems in the deployment and maintenance of networks using ISO
8473 (CLNP):
- ping or ISO Echo function
- traceroute function which uses the ISO Echo function
- routing table dump function
3. INTRODUCTION
Currently in the Internet, OSI protocols are being used more and
more. As the network managers of an Internet once
predominantly a TCP/IP network began deploying parts of the
emerging OSI Internet, it became apparent that network layer
ISO network debugging tools were for almost nonexisting. When
such tools existed, different implementations didn't work
together.
2
As stated in RFC 1139 a simple network layer mechanism is
necessary to allow systems to be probed to test network layer
integrity. RFC 1139 goes on to describe two different ping
capabilities, one a long term solution, and one a short term
solution. The problem becoming more and more prevalent in the
OSI Internet is that some vendors implemented the short term
solution and some implemented the long term one. The two
solutions do not work together, i.e., a ping from a host with the
short term version to one with the long term version will not
work, and visa versa. Also, some hosts and routers have not
implemented a ping at all. The two solutions provided to
simplify the situation, have instead complicated it.
4. SPECIFICATION
This document's purpose is to specify a standard ping,
traceroute, and OSI routing table dumping mechanisms for use for
the ISO 8473 (CLNP) protocol in the OSI Internet. A detailed
description of the specified mechanisms is below. These
mechanism should be available on every router (intermediate
system) or host (end system) that provides OSI service for
the Internet. These three functions are the basic tool set for
the OSI network
layer for the Internet.
4.1. PING
Protocol Support
-----------------
The long term echo mechanism, as described in RFC 1139,
requires the use of two new type values in the packet header of
the ISO 8473 Network Protocol Data Units (NPDUs). The two
values are:
1E(hex) - for the Echo Request Selector and,
1F(hex) - for the Echo Reply Selector.
Nodes which support ISO 8473 but do not support these two new
values (for the type code option field in the header of an ISO
8473 (NPDU) will send back an error packet IF the ERROR report
flag is set in the NPDU.
To support a ping function for ISO 8473, all end systems (hosts)
and intermediate systems (routers) must support the "long term"
echo function as defined by RFC 1139 AND also set the ERROR
report flag in the 8473 header.
The setting of the ERROR report flag is required because this
allows a way for a compliant host or router to ping a
3
DRAFT - OSI Tools March 14, 1991
non-compliant host or router. When a non-complaint host or
router receives a "ping" NPDU with the new type function (Echo
Request Selector), it will send back an ISO 8473 ER NPDU to the
originating host.
4.1.2) Functions to be supported in "ping" utility
A ping utility should able to provide the Round trip time of each
packet, plus the average minimum and maximum RTT over several
ping packets. When an ER NPDU is received by the node, the ping
utility should report the error code to the user.
4.2. TRACEROUTE
The CLNP trace is similar to the ping utility except that it
utilizes the "Lifetime" field in the ISO 8473 NPDU. The
"Lifetime" field serves the same function as the Time To Live
(TTL) field does in an IP packet. A node (router or host) cannot
forward ISO 8473 NPDU with a value for the Lifetime of zero. If
the ERROR REPORT flag is set in the ISO 8473 PDU, an ER (error)
NPDU will be returned to the originator of the packet.
4.2.1) Basic TRACEROUTE
If a ISO 8473 PDU with a type code of Echo-request is sent with
"Lifetime" field value of 1, the first hop node (router or end
system) will either return an ER NPDU to the originator the NPDU.
If the first hop node supports the "Echo-Request" type field the
error code will be either:
A0 (hex) - Lifetime Expired while Data Unit in Transit
A1 (hex) - Lifetime Expired during Re-assembly
If the first hop node does not support "Echo-Request" type field,
please return the Error code:
B0 (hex) - Unsupported Option not Specified.
When trying to trace a route to a remote note, the destination
address in the Echo-Request PDU sent should be this remote
destination. By using increasing values in the "Lifetime" field
a route can be traced through the network to the remote node.
This traceroute function should be implemented on each system
(host or router) to allow a user to trace a network path to a
remote host.
4
DRAFT - OSI Tools March 14, 1991
The error message is used as evidence of what the first hop was.
The originator then sends a packet with a "lifetime" field value
of 2. The first hop decrements the "Lifetime" and because the
"Lifetime" is still greater than 0, it forwards it on. The
second hop decrements the "Lifetime" field value and sends an
Error PDU (ER NPDU) with one of the two "Lifetime Expired" error
codes listed above to the originator. This sequence is repeated
until either:
- the remote host is reached an either an
Echo-Reply PDU is sent back or (for
nodes that do not have the required
Echo support) an ER PDU is sent back, or
- the an ER PDU is received with error code (B0) indicating
that a node will not pass the Echo-Reply packet, or
- an ER NPDU is received with one of the following errors:
80(hex) - Destination Address Unreachable
81(hex) - Destination Address Unknown.
If any of the following Error codes are received in an ER PDU, a
second PDU should be sent by the originating node:
Code Reason from 8473
-----------------------------
00(hex) - Reason not specified
01(hex) - Protocol procedure error
02(hex) - Incorrect checksum
03(hex) - PDU Discarded due to Congestion
04(hex) - Header Syntax Error (cannot be parsed)
05(hex) - Segmentation needed but not permitted
06(hex) - Incomplete PDU received
07(hex) - Duplicate Option
B1(hex) - Unsupported Protocol Version
B2(hex) - Unsupported Security Option
B3(hex) - Unsupported Source Routeing Option
B4(hex) - Unsupported Recording of Route Option
C0(hex) - Reassembly Interface
If one of these error is detected, please return the error value
to the user. More than two Echo NPDUs, may be sent at a
"Lifetime" value. The number of additional echo NPDUs is left up
to the implementation of this traceroute function.
If one of the following errors is received, AND "partial source
route" is not specified in the Echo-Request NPDU, send a second
Echo-Request NPDU to the destination at a "Lifetime" value:
5
DRAFT - OSI Tools March 14, 1991
Code Reason from 8473
--------------------------------
90(hex) Unspecified Source Routeing Error
91(hex) Syntax Error in Source Routeing Field
92(hex) Unknown Address in Source Routeing Field
93(hex) Path not Acceptable
(The Echo-request NPDU may have been damaged in shipping through
the network.)
4.2.2) Use of Partial Source route in traceroute
The current IP traceroute has a 3rd party or "loose source route"
function. The ISO 8473 protocol also supports a "partial source
routeing" function. However, if a node (router or host) does not
support the "partial source routeing" function a ISO 8473 NPDU
gets passed along the path "exactly as though the function has
not been selected. The PDU shall not be discarded for this
reason."[3]
A partial source route function in the ISO Traceroute will set in
the option fields the "source routeing" option, and the "partial
source routeing" parameter within that option. To support a 3rd
party or "loose source route" traceroute function, a node will
send the Echo-Request NPDU with the "loose source routeing" field
set.
The functioning of the 3rd party/"loose source route" traceroute
is the same except the following error cause the traceroute to be
terminated:
Code Reason from ISO 8473
--------------------------------------------------
92 Unknown Address in Source Routeing Field
93 Path not Acceptable
These errors may indicate a problem with the "loose source route"
listed in the Echo-Request NPDU for this destination. Additional
NPDUs with the same lifetime will only repeat this error. These
errors should be reported to the user of the traceroute function.
4.2.3) Information needed from a Traceroute utility
A traceroute utility should provide the following information to
the user:
- NET systems the pathway goes through,
- ping times (in Round trip times) for each
step of the way,
- error codes from ER PDU received as a
6
DRAFT - OSI Tools March 14, 1991
response to the an Echo-Request packet, and
- any other error conditions encounter
by traceroute.
4.3. OSI routing table dump
Each OSI host (end system) or router (intermediate system)
need to be able to dump any of its routing tables. Routing
tables may come from the:
a.) the ES-IS information
b.) static
c.) IS-IS
d.) IDRP
or any other source.
Each system must be able to dump the routing table entries from
the console. A method must exist to provide these. It is
suggested that a showosi routes command be created with the
following options:
- a for all routes
- esis for es-is routes
- isis for is-is routes
- idrp for idrp routes
- static for static routes
- other for routes from other sources.
In addition, it is optional but highly recommended that the
routing tables be available from via of the following network
protocols:
a.) SNMP
Internet MIBs
RFC 1238 CLNS MIB [4]
NET of this router
ES adjacencies,
ES Connection Timer,
ES hold timer
IS Adjacencies
RFC XXXX Integrated IS-IS MIB [5]
(***Editor's note - this is the type of information
7
DRAFT - OSI Tools March 14, 1991
I think should be included, but I need feed back on
this prior to specifying particular MIB variables.)
IS Reachability information
IS L1 Adjacencies
IS L2 ADjacencies
RFC XXXX IDRP MIB [6]
(***Editor's note - this is the type of information
I think should be included, but I need feed back on
this prior to specifying particular MIB variables.)
per BIS router:
InternalBIS,
IntraIS,
ExternalBISNeighbor,
Internal Systems,
LocalRDI,
RDC-Config,
Local-SNPA,
MultiExit,
RouteServer
holdTime,
CloseWaitDelay
Local RIB
Local FIB
per BIS neighbor:
BIS_NET
BIS_RDI
BIS_RDC
Adj-RIB information
b.) CMIP agent
ISO 10733 [7] (Common network layer)
Section 6.4)
Network Entity Managed Object
networkEntityTitles
linkage-ISO9542ES-P
HoldingTimerMultipler
manualISSNPAAddress
defaultESConfigTimer
activeESConfigTimer
isReachabilityChanges
linkage-ISO9542IS-P
holdingTimerMultiplier
isConfigurationTimer
suggestedESConfigurationTimer
8
DRAFT - OSI Tools March 14, 1991
redirectHoldingTimer
eSReachabilityChanges
ISO 10589 [8] (IS-IS) - GDMO
(***Editor's note - this is the type of information
I think should be included, but I need feed back on
this prior to specifying particular MIB variables.)
IS Reachability information
IS L1 Adjacencies
IS L2 ADjacencies
ISO 10747 [3] (IDRP) - GDMO
(***Editor's note - this is the type of information
I think should be included, but I need feed back on
this prior to specifying particular MIB variables.)
per BIS router:
InternalBIS,
IntraIS,
ExternalBISNeighbor,
Internal Systems,
LocalRDI,
RDC-Config,
Local-SNPA,
MultiExit,
RouteServer
holdTime,
CloseWaitDelay
Local FIB
Local RIB
per BIS neighbor:
BIS_NET
BIS_RDI
BIS_RDC
Adj-RIB information
9
DRAFT - OSI Tools March 14, 1991
5. REFERENCES
[1] ISO/IEC 8473, Information Processing Systems, "Protocol
for Providing the Connectionless-mode Network Service and
Provision of Underlying Service". May, 1987.
[2] R. Hagens, "An Echo Function for ISO 8473", Request For
Comment #1139, January 1990. DDN Network Information
Center, SRI International.
[3] ISO/IEC DIS 10747 Information Processing Systems -
Telecommunications and Information Exchange between Systems -
Protocol for Exchange of Inter-domain Routeing Information among
Intermediate Systems to Support Forwarding of ISO 8473 PDUs.
[4] RFC 1238 CLNS MIB (Greg Satz) - for use with Connectionless
Network Protocol (ISO 8473) and End system to Intermediate System
Protocol (ISO 9452)
[5] RFC xxx Integrated IS-IS MIB - (Chris Gunner)
[6] RFC xxxx IDRP MIB (Hares)
[7] ISO/IEC 10733 - Information Technology - Telecommunications
and Information Exchange between Systems - Elements of Management
Information Relating to OSI Network Layer Standards
[8] ISO/IEC 10589 - Information Processing Systems -
Telecommunications and Information Exchange between Systems -
Protocol for Exchange of Intra-Domain Routeing Information among
Intermediate Systems.
10
DRAFT - OSI Tools March 14, 1991
TABLE OF CONTENTS
Section 1 STATUS ...................................... 2
Section 2 ABSTRACT .................................... 2
Section 3 INTRODUCTION ................................ 2
Section 4 SPECIFICATION ............................... 3
Section 4.1 PING ...................................... 3
Section 4.2 TRACEROUTE ................................ 4
Section 4.3 OSI routing table dump .................... 7
Section 5 REFERENCES .................................. 11
11